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VICTORY  Architecture  DoT  &  Orientation  Service  Validation 

Experiments 


1.0  Introduction 

This  document  describes  a  set  of  validation  experiments  and  will  provide  verification  and 
validation  of  the  VICTORY  1.0  Architecture  DoT  (Direction  of  Travel)  &  Orientation  service 
specifications.  The  DoT  &  Orientation  service  when  implemented  correctly  and  with  the 
standard  format  specified  by  the  VICTORY  1.0  will  provide  DoT  &  Orientation  data  to  the 
VDB  (Victory  Data  Bus)  as  shown  in  Figure  1.  The  main  components  and  interfaces  being 
evaluated  on  the  VDB  (VICTORY  Data  Bus)  include 

o  DoT  &  Orientation  data  VDM  (VICTORY  Data  Message) 
o  VDB  DoT  &  Orientation  Data  Interface 
o  VDB  DoT  &  Orientation  Management  Interface 


Figure  1:  VICTORY  Services  network  as  implemented  in  the  VIDS 

The  experiments  will  evaluate  these  interface  specifications  by  integrating  software  clients 
and  services  developed  using  the  specifications,  and  evaluating  the  resulting  functional 
behavior  and  performance.  The  TARDEC  Vehicle  Electronics  and  Architecture  (VEA)  group 
executed  this  set  of  additional  validation  experiments,  utilizing  their  VICTORY 
Interoperability  &  Development  System  Integration  Laboratory  (VIDS) 
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2.0  Experiment  Goals 

o  Evaluate  the  completeness  and  unambiguousness  of  the  individual  interface 
specifications  of  each  included  service. 

o  Investigate  the  resulting  functional  performance  of  reference  implementations  of 
the  interfaces  integrated  with  representative  hardware. 

3.0  Experiment  Design 

The  experiments  in  this  set  all  leverage  a  common  hardware  and  software  design.  The 
Physical/Logical  block  diagram  for  testing  the  DoT  &  Orientation  service  is  shown  in  Figure 
2.  The  two  test  tools  used  for  managing  and  monitoring  the  DoT  &  Orientation  VDM’s  are, 

a.  WiresharkVDB  plug-in 

b.  DoT  &  Orientation  Service  Management  Interface 


0 

c 


(  IMU 
HW  1 


DOT  &  Orientation  Service  Host: 

Ethernet 

*  Orientation  Management  Server 

Orientation  Data  Server 

*  DOT  Management  Server 

*  DOT  Data  Server 

Ethernet  Switch 


Ethernet 


-> 


DOT  &  Orientation  Host  1 : 
WiresharkVDB  Plug-In 


Ethernet 


DOT  &  Orientation  Hosts  2: 
DOT  &  Orientation  Service 
Management  Interface 


Figure  2:  Block  Diagram  for  DoT  &  Orientation  Service  Testing. 


3.1  Wireshark  VDB  Plug-in 

A  custom  dissector  plug-in  for  Wireshark  version  1.2.8  is  developed  for  the  VIDS  lab  and  is 
used  as  a  tool  for  testing  and  monitoring  VDM’s.  This  dissector  captures  UDP  VICTORY  Data 
Messages  (VDMs)  and  breaks  them  down  into  their  specific  header  and  data  fields  as  show 
in  Figure  3.  It  also  provides  a  filter  to  look  for  VDM  messages  and  the  ability  to  log  captured 
VDMs  to  a  formatted  text  file.  Each  properly  formatted  VDM  packet  contains  a  "Header”  field 
and  a  "Data”  field,  which  can  be  expanded  upon  as  described  in  the  following  sections. 

The  DoT  is  a  derived  VDM  from  the  Orientation  VDM  and  the  Position  VDM.  All  the  static 
results  that  are  applicable  to  the  Orientation  and  Position  VDM  are  proxy  validation  for  the 
DoT  VDM.  The  DoT  Static  Parameter  Results  are  shown  along  with  the  Orientation  results, 
whereas,  the  dynamic  measurements  and  results  are  shown  separately  following  the 
Orientation  results  in  the  following  sections. 
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Figure  3:  Wireshark  VDB  Plug-in  Screen  Shot(s)  for  DoT  &  Orientation 

3.2  Terminal  &  GUI  Client's  for  DoT  &  Orientation  VDM  Management 

In  addition  to  the  Wireshark  plug-in  to  view  the  data  and  header,  two  clients  are 
developed  to  manage  the  VDM’s.  One  is  a  command  line  client  and  the  other  is  a  GUI 
based  client  as  shown  in  Figure  4  &  Figure  5.  Both  of  these  clients  perform  the  same 


File  Edit  View  Jerminal  Tabs  Help 

File  Edit  View  Terminal  Tabs  Help 

Supported  commands  include: 

Supported  commands  include: 

1)  getDoTNominalDataAvailable 

1)  getOrientationNominalDataAvailable 

2)  getDoT 

2)  getOrientation 

3)  setDoT 

3)  setOrientation 

4)  getlnterfaceType 

4)  getlnterfaceType 

5)  getlnterfaceStandardVersion 

5)  getlnterfaceStandardVersion 

6)  getConfigurationVersion 

6)  getConfigurationVersion 

7)  getDataEnabled 

7)  getDataEnabled 

8)  setDataEnabled 

8)  setDataEnabled 

9)  getTimeUncertainty 

9)  getTimeUncertainty 

10)  getDataTransportConfiguration 

10)  getDataT ransportConf iguration 

11)  setDataTransportConfiguration 

11)  setDataTransportConfiguration 

12)  getUpdatePeriod 

12)  getUpdatePeriod 

13)  setUpdatePeriod 

13)  setUpdatePeriod 

14)  getMinimumUpdatePeriod 

14)  getMinimumUpdatePeriod 

15)  getFaults 

15)  getFaults 

16)  quit 

16)  quit 

Please  enter  command  or  '--help1 

6 

Please  enter  command  or  '--help' 

6 

Calling  getConfigurationVersion. 

Calling  getConfigurationVersion. 

Return  code:  0 

Return  code:  0 

Configuration  version:  TARDEC_VEA_VIDS_1 . 0 

Configuration  version:  TARDEC_VEA_VIDS_1 . 0 

Done  calling  getlnterfaceStandardVersion. 

Done  calling  getlnterfaceStandardVersion. 

Figure  4:  Terminal  Client  for  DoT  &  Orientation  VDM  Management 


VICTORY  Architecture  Position  Service  Validation  Testing 

UNCLASSIFIED 


Page  |  6 


UNCLASSIFIED 


Figure  5:  GUI  Client  for  DoT  &  Orientation  VDM  Management 


4.0  Specifications  Evaluated 

The  VICTORY  Architecture  1.0  standards  are  specified  in  the  Version  1.0  document  released 
on  July  29, 2011.  The  following  are  the  standards  that  were  evaluated 

o  VICTORY  Data  Management  Interface  <10008-20110729,  Pro> 
o  SOAP  Compliance  and  Standards  <10001-20110729,  Pro> 
o  Application  Layer  Data  Encoding  <20001-20110729,  Pro> 
o  Application  Layer  Message  Encapsulation  <20002-20110729,  Pro 
o  Timestamp  Format  for  Application  Layer  Data  <20004-20110729,  Pro  > 
o  DoT  &  Orientation  Data  Interface  <20007-20110729  &  20008-20110729,  Pro 
o  DoT  &  Orientation  Management  <15001-20110729  &  15002-20110729,  Pro 
o  DoT  &  Orientation  Interface  Complex  Types  <20012-20110729  &  20013- 
20110729,  Pro 

5.0  Change  Proposals  Validated 

The  VICTORY  Architecture  1.0  standards  are  specified  in  the  Version  1.0  document  released 
on  July  29,  2011.  The  following  are  the  change  proposals  that  were  validaed 

o  AIWG  CP  003:  Direction  of  Travel  Service  Data  Message  Information  Content 
o  AIWG  CP  010:  Direction  of  Travel  Service  Data  Message  Information  Format 
o  AIWG  CP  004:  Direction  of  Travel  Service  Management  Parameters 
o  AIWG  CP  016:  Direction  of  Travel  Management/Configuration  Interface 
Specification 

o  AIWG  CP  005:  Orientation  Service  Data  Message  Information  Content 
o  AIWG  CP  012:  Orientation  Service  Data  Message  Information  Format 
o  AIWG  CP  006:  Orientation  Service  Management  Parameters 
o  AIWG  CP  017:  Orientation  Management/Configuration  Interface  Specification 
o  AIWG  CP  Oil  -  Data  Message  Format 
o  AIWG  CP  014  -  Application  Management  Core  Technology 
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o  AIWG  CP  019  -  Timestamp  Format  on  the  VDB 

o  AIWG  CP  020  -  Encapsulation  of  Data  Messages  Into  Network  Payloads 


6.0  List  of  Experiments 

This  experiment  set  is  composed  of  the  following  procedures: 

o  DoT  &  Orientation  Management  Static  Parameters 
o  DoT  &  Orientation  Data  Enabled 
o  DoT  &  Orientation  Data  Validity 
o  Update  Period 
o  Sequence  number  continuity 
o  System  Resource  Usage 
o  End-to-End  Latency 


7.0  Procedure  1:  DoT  &  Orientation  Management  Static  Parameters 

The  DoT  &  Orientation  management  interface  must  maintain  a  set  of  static  parameters  and 
supply  them  to  the  client’s  request.  This  procedure  will  evaluate  whether  the  DoT  & 
Orientation  management  service  can  reply  to  the  client’s  GetQ  requests  on  all  static 
parameters.  The  list  of  static  parameters  includes:  DoT  &  Orientation  data  management 
specific  parameters,  version  information  management  specific  parameters  (interface  type, 
interface  standard  version  and  configuration  version)  and  VICTORY  data  management 
specific  parameters  (time  uncertainty  and  minimum  update  period). 

A  terminal  DoT  &  Orientation  management  client  described  in  the  previous  section  3.0  is 
used  to  execute  Get()  commands  on  all  of  the  static  parameters  mentioned  above.  The 
results  of  those  GetQ  commands  are  recorded  and  compared  to  the  specification  to 
determine  their  validity. 

Procedure  Details 

a.  Execute  a  get()  command  on  every  static  parameter 

b.  Write  down  the  received  values 

c.  Although  the  specification  doesn’t  declare  the  format  and  range  of  the  static 
parameters,  all  static  parameters  are  implicitly  assumed  to  have  the  same  values  as 
the  ones  in  the  'Static  Configuration  Settings’  file.  Therefore  the  received  values  from 
the  get()  request  should  be  compared  with  the  ‘Static  Configuration  Settings’  file. 


Results 

•  The  received  values  from  the  get()  request  compared  with  the  ‘Static  Configuration 
Settings'  file  are  shown  in  Table  1  below,  the  values  from  the  get()  compare 
identically  with  the  settings  from  the  ‘Static  Configuration  Settings'  file. 
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Static  parameters 

Values  received  by 
the  Orientation 
client 

Values  received  by  the 
DoT  client 

Values  stored  in  the 
'Static  Configuration 
Settings'  file(s)  for 
Orientation/DoT 

Interface  ID 

N/A 

N/A 

N/A 

Source  ID  list 

N/A 

N/A 

N/A 

Interface  type 

Orientation 

DoT 

Orientation/DoT 

Interface  standard 
version 

1.0 

1.0 

1.0 

Configuration  Version 

T  ARD  E  C_VE  A_VI  D  S_ 

1.0 

TARDEC_VEA_VIDS_1.0 

TARDEC_VEA_VIDS_1.0 

Geodetic  datum 

N/A 

N/A 

N/A 

Timestamp  uncertainty 

0 

0 

0 

Minimum  update  period 

0 

0 

0 

Nominal  data  available 

0,  0,0 

0,  0,0 

0,  0,0 

Table  1:  DoT  &  Orientation  service  Static  Parameters  results 

8.0  Procedure  2:  DoT  &  Orientation  Data  Enabled 

Data  enabled  is  a  parameter  that  identifies  whether  the  DoT  &  Orientation  data  interface  is 
sending  out  data.  This  procedure  validates  whether  the  DoT  &  Orientation  Management 
Interface  can  reply  to  GetQ  and  SetQ  requests  on  data  enabled  and  whether  the  flow  of  DoT 
&  Orientation  data  is  properly  controlled  by  the  data  enabled  parameter. 

This  procedure  starts  by  using  a  DoT  &  Orientation  management  client  to  send  a  data 
enabled  SetQ  command  with  value  of  True  to  the  DoT  &  Orientation  management  interface. 
After  processing  the  SetO  command,  the  DoT  &  Orientation  management  interface  is 
supposed  to  enable  the  flow  of  DoT  &  Orientation  VDMs,  which  will  be  verified  using  the 
Wireshark  VDM  Plug-in  described  in  Section  3.0  with  appropriate  network  filters.  Then  the 
DoT  &  Orientation  management  client  will  send  a  GetQ  command  to  the  DoT  &  Orientation 
management  interface  for  data  enabled  parameter,  with  an  expected  value  of  True  as  it  was 
set  previously.  Next  the  DoT  &  Orientation  management  client  will  send  another  SetQ 
command  on  data  enabled  with  the  value  of  False  this  time.  Wireshark  will  again  verify  that 
there  is  no  longer  any  DoT  &  Orientation  VDMs  sent  out.  The  DoT  &  Orientation 
management  client  will  send  a  data  enabled  GetQ  command  to  ensure  that  the  received 
value  is  False.  After  that  the  DoT  &  Orientation  management  client  will  set  the  value  of  data 
enabled  to  True  again,  and  Wireshark  will  verify  that  DoT  &  Orientation  VDMs  is  sent  out 
also.  Finally,  the  DoT  &  Orientation  management  client  will  send  out  a  GetQ  request  to 
ensure  that  the  value  of  data  enabled  is  True. 

Procedure  Details 

a.  Use  the  client  to  set  the  update  period  to  1  second 

b.  Execute  a  setQ  command  on  data  enabled  property  to  True 
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c.  Verify  on  Wireshark  that  DoT  &  Orientation  data  is  being  sent  out  periodically  for  at 
least  10  update  periods 

d.  Execute  a  getQ  command  on  data  enabled  property 

e.  Verify  that  the  received  value  is  1 

f.  Execute  a  setQ  command  on  data  enabled  property  to  False 

g.  Verify  on  Wireshark  that  DoT  &  Orientation  data  stops  sending  out  for  a  time  out  of 
at  least  10  update  periods 

h.  Execute  a  getQ  command  on  data  enabled  property 

i.  Verify  that  the  received  value  is  0 

j.  Set  the  data  enabled  property  back  to  True 

k.  Verify  on  Wireshark  that  the  DoT  &  Orientation  data  is  sent  out  periodically  for  at 
least  10  update  periods 

l.  Use  the  client  to  request  data  enabled  property  and  verify  that  it  is  1 

Results 

•  Both  GetQ  and  SetQ  commands  work  on  the  data  enabled  setting. 

•  When  the  data  enabled  property  is  1  (True),  DoT  &  Orientation  data  is  sent  out 
periodically. 

•  When  the  data  enabled  property  is  0  (False),  DoT  &  Orientation  data  stops  sending 
out. 

•  Overall,  the  outcome  matches  the  expected  response. 

9.0  Procedure  3:  DoT  &  Orientation  Data  Validity 

Before  sending  out  DoT  &  Orientation  VDMs,  the  DoT  &  Orientation  data  interface  must 
populate  all  necessary  fields  of  the  binary  header,  formulate  the  XML  payload  according  to 
the  DoT  &  Orientation  data  schema  and  preserve  the  integrity  of  the  raw  data  sampled  from 
any  IMU  (Inertial  Momentum  Unit)  and  the  GPS  source(s).  This  procedure  will  determine 
the  integrity  of  DoT  &  Orientation  data  values  and  the  validity  of  binary  header  and  XML 
payload.  It  will  also  determine  if  DoT  &  Orientation  data  can  be  extracted  from  the  DoT  & 
Orientation  VDMs  in  an  unambiguous  way.  In  this  procedure,  raw  DoT  &  Orientation  data 
will  be  generated  using  the  IMU  (Inertial  Momentum  Unit)  and  the  GPS  and  fed  to  the  DoT  & 
Orientation  data  service  server’s,  which  in  turn  generate  and  broadcast  the  DoT  & 
Orientation  VDMs  that  will  be  analyzed  and  validated  as  they  are  captured  at  the  data  sinks. 

Procedure  Details 

a.  Position  VDMs  are  available  on  the  VDB. 

b.  Use  IMU  data  input  to  feed  the  current  orientation. 

c.  Run  Orientation  Server  to  read  IMU  data  and  generate  Orientation  VDM. 

d.  Run  DoT  Server  to  read  Orintation  and  Postion  VDM’s  and  generate  DoT  VDM. 

e.  Start  a  client  connection (s)  to  the  DoT  &  Orientation  Service  Management 

f.  Execute  a  setQ  command  on  data  enabled  property  to  True 

g.  Run  the  DoT  &  Orientation  Data  Sink(s)  for  an  hour  to  interpret  VDM  multicast 
messages  and  validate  the  data 

h.  The  DoT  &  Orientation  Data  Sink(s)  will  write  the  validation  result  into  a  log  file 
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Results 

•  All  messages  have  valid  binary  header. 

•  For  the  implementation  evaluated: 

-  The  DoT  &  Orientation  values  received  and  extracted  from  the  VDB  matched 
the  values  that  the  service  encapsulated  and  sent  in  the  VDM. 

-  The  DoT  &  Orientation  values  sent  out  by  the  data  service  is  identical  to  the 
raw  IMU  and  GPS  values. 


10.0  Procedure  4:  Update  Period 

The  DoT  &  Orientation  management  service  must  allow  dynamic  GetQ  and  Set()  functions 
on  update  period  parameter.  The  DoT  &  Orientation  data  service  should  also  arrange 
transmission  delay  between  each  DoT  &  Orientation  VDM  in  consistence  with  the  update 
period  parameter.  The  DoT  &  Orientation  management  client  will  set  the  update  period  to 
different  values.  At  each  value,  DoT  &  Orientation  VDMs  will  be  collected  for  an  hour  and 
analyzed  to  determine  if  the  update  period  value  is  consistent  with  the  transmission  period 
between  each  DoT  &  Orientation  VDM.  Consistency  is  a  subjective  criterion  in  this  case. 
Procedure  Details 

a.  Use  the  client  to  query  the  DoT  &  Orientation  Management  Service  for  minimum 
update  period 

b.  Do  a  setQ  command  to  change  the  update  period  to  its  minimum 

c.  Get[)  the  value  and  verify  it  was  set  correctly 

d.  Use  the  DoT  &  Orientation  Data  Sink  to  listen  to  DoT  &  Orientation  multicast  stream 
and  collect  DoT  &  Orientation  data  for  an  hour.  The  DoT  &  Orientation  Data  Sink  will 
record  the  timestamps  and  differences  between  successive  timestamps  into  a  file. 

e.  At  the  same  time,  use  Wireshark  with  the  appropriate  capture  filter  to  capture  DoT  & 
Orientation  data  messages 

f.  Calculate  the  average  of  the  list  of  period  between  successive  timestamps  from  the 
record  file 

g.  Use  Wireshark  to  generate  average  packets/sec  statistic.  Its  inverse  will  be  the 
average  update  period. 

h.  Record  the  value  from  Wireshark 

Results 

Wireshark  results  were  captured  for  a  period  of  lhour.  The  average  update  period  for  the 
VDM  message  set  for  a  lsec  update  period  is  calculated  and  show  below. 


Update  Period  Setting 

Average  value  update  for 
Orientation  VDM  message  from 
Wireshark 

Average  value  update  for  DoT 
VDM  message  from  Wireshark 

1  sec 

1.0010927  sec 

1.0010300  sec 

Table  2:  DoT  &  Orientation  Service  Update  Period  results 
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11.0  Procedure  5:  Sequence  number  continuity 

The  DoT  &  Orientation  data  interface  must  tag  each  message  with  a  monotonically 
increasing  sequence  number  before  sending  it  out.  To  validate  the  sequence  number  of  DoT 
&  Orientation  VDMs,  the  number  of  discontinuities  will  be  recorded.  DoT  &  Orientation 
VDMs  will  be  continuously  sent  out  for  an  hour,  and  a  DoT  &  Orientation  data  sink  will 
analyze  the  continuity  of  sequence  numbers  of  all  DoT  &  Orientation  VDMs. 

Procedure  Details 

a.  Use  the  client  to  query  for  the  minimum  update  period 

b.  Set  the  update  period  to  twice  the  minimum  period 

c.  Perform  a  getQ  command  to  verify  that  the  update  period  was  set  correctly 

d.  Use  the  DoT  &  Orientation  Data  Sink  to  check  if  the  sequence  number  increases 
monotonically 

e.  Allow  DoT  &  Orientation  Data  Sink  run  for  one  hour  and  record  sequence  number 
discontinuities 


Result 

Received  sequence  numbers  increases  monotonically  without  any  discontinuities. 

12.0  Procedure  6:  System  Resource  Usage 

This  procedure  will  investigate  the  computing  resources  required  to  interpret  DoT  & 
Orientation  messages.  The  recommended  metrics  for  system  resource  usage  is  XML 
processing  time. 

Procedure  Details 

a.  Start  the  DoT  &  Orientation  Data  Service  at  a  reasonable  update  rate 

b.  Use  the  DoT  &  Orientation  Data  Sink  to  collect  values  of  processing  time  and  memory 
used  during  the  interpretation  and  validation  of  VDM  messages 

c.  Display  the  results  in  the  log  file  graphically 

ranges  from  52,000  nsec,  to  110,000  nsec, 
with  some  sporadic  peaks  up  to 
114,000  nsec  as  shown  in  Figure  6.  The 
average  XML  build  time  is  97,322  nsec 
and  Std  Dev  of  2,869  nsec. 


Figure  6:  VDM  build  time  for 
Orientation  Service 


Result 

The  processing  time  for  creating  Orientation  VDM 
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The  processing  time  for  creating  Orientation  VDM  ranges  from  52,000  nsec,  to  180,000 

nsec,  with  some  sporadic  peaks  up  to 
180,000  nsec  as  shown  in  Figure  6.  The 
average  XML  build  time  is  95,991  nsec 
and  Std  Dev  of  3,989  nsec. 
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Figure  7:  VDM  build  time  for  DoT 
Service 


13.0  Procedure  7:  End-to-End  Latency 

The  accuracy  of  orientation  data  depends  on  the  latency  from  the  orientation  sensor  output 
to  the  received  corresponding  update  from  the  Orientation  Data  Service.  This  experiment 
will  evaluate  this  end-to-end  latency  by  measuring  the  time  it  takes  to  transfer  an 
orientation  value  on  the  serial  port  of  the  sensor  into  an  orientation  VDM  received  by  an 
orientation  data  sink 

Procedure  Details 

a.  Configure  Orientation  Data  Service  to  sample  values  over  Ethernet  connection 

b.  Start  the  Orientation  Data  Service  at  a  specified  update  period  (1  sec  for  this 
reference  implementation) 

c.  Start  Wiershark  Orientation  Data  Sink.  It  processes  received  orientation  VDMs,  it 
keeps  track  of  2  timestamps:  one  when  the  VDM  was  created  (within  the  VDM)  and 
another  when  the  updated  VDM  is  received.  The  end  to  end  latency  of  orientation 
data  is  calculated  by  subtracting  those  2  timestamps  and  recorded  into  a  log  file. 

d.  Stop  the  Orientation  Data  Sink  after  about  60  minutes 

e.  Open  the  latency  log  file  and  display  the  results  graphically 

f.  The  same  test  is  repeated  except  the  DoT  service  originates  the  DoT  VDMs  (The  DoT 
VDM  is  created  using  Position  VDM  and  the  Orientation  VDM  available  on  the  VDB). 
The  rest  of  the  procedure  remains  the  similar  to  the  previous  test,  except  the  End-to- 
End  Latency  is  calculated  with  the  origination  time  at  the  DoT  Sserver. 


Result: 

The  results  displayed  below  show  the  complete  DoT  &  Orientation  VDM  creation,  broadcast 
and  consumption  time,  i.e.  end-to-end  latency  as  shown  in  Figure  7. 
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The  End-To-End  time  for  creating 
Orientation  VDM,  transmitted  and 
sinking  the  VDM  ranges  from  60,000 
NanoSec.  to  105,000  Nano  Sec.  with  some 
sporadic  peaks  up  to  140,000  Nano  Sec 
and  Std  Dev  of  3,038  nsec. 


Figure8:  VDM  end-to-end  time  for 
Orientation  Service 
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The  End-To-End  time  for  creating  DoT 
VDM,  transmitted  and  sinking  the  VDM 
ranges  from  110,000  NanoSec.  to 
120,000  Nano  Sec.  with  some  sporadic 
peaks  up  to  150,000  Nano  Sec  and  Std 
Dev  of  4,015  nsec. 


Figure_9:  VDM  end-to-end  time  for  DoT 
Service 


14.0  Conclusion 

The  experiments  performed  in  the  VIDS  evaluated  the  VICTORY  Architecture  Standards  1.0 
interface  specifications  by  integrating  software  clients  and  services  developed  to  the 
specifications,  and  evaluated  the  resulting  functional  behavior  and  performance.  In 
conclusion,  the  DoT  &  Orientation  service  as  specified  for  the  1.0  standard  as  implemented 
in  the  VIDS  is 

o  Complete  and  unambiguous  of  the  individual  interface  specifications  of  each 
included  service. 

o  The  resulting  functional  performance  of  this  reference  implementation  with  the 
representative  hardware  is  adequate  to  the  current  development  needs  of  the 
VICTORY  architecture. 

The  next  step  in  validating  the  service  is  determining  whether  interoperability  is  achieved 
when  multiple  implementers  develop  to  the  specifications.  These  tests  will  be  conducted  in 
the  VIDS  and  the  results  will  be  published. 
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15.0  Open  Issues  for  Future  Testing 

The  testing  completed  at  this  stage  included  only  the  verification  of  the  standard  for  the 
standalone  DoT  &  Orientation  Service.  Future  testing  will  include  interoperability  testing, 
system  level  testing  and  end-user  testing.  To  include  the  services  for  integrating  to  end  user 
applications  the  following  tests  will  be  done  and  the  ensuing  development  will  be 
recommended. 

o  Notification  to  the  user  and  the  application  when  the  IMU  Sensor  is  down. 

Recommend  mitigation  actions  to  the  standard  specifications  or  at  the  application 
end. 

o  Test  and  report  the  limit  to  data  broadcast  frequency  i.e.  the  update  period  and 
limit  to  the  number  of  connections  (open  sockets)  to  the  data  server  when 
multiple  services  (Position,  DoT  &  Orientation,  Threat,  RWS  etc.)  are 
implemented  on  the  same  server. 
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